Smart Placement

Smart Placement is only active for Workers that make multiple roundtrips (more than or equal to two roundtrips) to back-end infrastructure. If your Worker only does a single subrequest to your back-end infrastructure, the Smart Placement algorithm will not move your Worker. If the Worker has multiple back-end services, the algorithm determines the best placement for the Worker that will minimize total overall RTT.

Smart Placement is a best-effort attempt. If it is more performant to not move the Worker, (for example, if you are using a distributed back end) the algorithm will take no action.

Smart Placementは、バックエンド インフラストラクチャに複数のラウンドトリップ（2往復以上）を行うWorkerに対してのみ有効です。Workerがバックエンドインフラへのサブリクエストを1回しか行わない場合、Smart PlacementアルゴリズムはWorkerを移動させません。Worker に複数のバックエンド サービスがある場合、アルゴリズムは、全体の RTT の合計を最小化する Worker の最適な配置を決定します。

Smart Placementはベストエフォート（最善の努力）の試みです。Worker を移動しない方がパフォーマンスが高い場合（たとえば、分散型バックエンドを使用している場合）、アルゴリズムは何も行いません。

​​

たとえば

ユーザーが日本からアクセスすると、Workerは日本のエッジにアクセスする（近いし、そもそもそれがエッジWorker）

ただ、そこから北米にあるDBサーバーにアクセスしてたとしたら？

もしそれが1RTですまず、複数回のアクセスだったとしたら？

この場合、Worker自体もDBのある北米に移してしまうほうが、パフォーマンスが向上するというわけ

簡易的なAAで-をネットワーキングと表現するならば、

日本 - 日本 === 北米: =のところが遅い

日本 --- 北米 = 北米: =のところが速いので結果的に速い

というのを体感できるデモ

そもそもエッジとしては、ユーザーに近いところでサクッと実行される想定だった

が、ユースケースが拡大するにつれ、やはりデータベースありきだと気づいた

なのでリージョンを指定できないことが逆に問題になるケースもあった

もちろんKV，DO, D1みたいなCloudflareスタックであれば、その心配はもともとないけど

機能を有効にするには、Workerごとにフラグを1つ立てるだけ

Dashboardからでも、wrangler.tomlからでも

ロケーションは自動的に賢く選んでもらえる

移転しないほうがパフォーマンスがよければ、移転しない

そもそも1RTしかしてないなら、移転しない、などなど

これは普通に嬉しいやつ。

DBがアメリカにあるなら、日本のエッジでリクエスト受けても嬉しいことあんまないのでは？ってずっと思ってたので。

ただService bindingsとの使い分けとか、そのへんは気になるところ。自動でお手軽にやりたいならって感じ？